In SIP networks, the sender identification information included in an INVITE message used for establishing a session may include the information in the “From” header field. This information typically includes the display name of the sender and the sender's address of record (AOR). The address of record is frequently thought of as the public address of the user. The display name of the user is the name that may be displayed by a SIP terminal. In SIP networks, the address of record is the public address at which other nodes can contact the entity. in one exemplary definition, an address of record is a SIP or SIPS uniform resource identifier (URI) that points to a domain with a location service that can map the uniform resource identifier (URI) to another URI where the user might be available. According to Internet engineering task force (IETF) request for comments (RFC) 3261, the disclosure of which is incorporated by reference herein in its entirety, the “To” header field contains the address of record whose registration is to be created, queried, or modified. Typically, the location service is populated through registrations.
One problem associated with conventional SIP registration operation described in RFC 3261 is registration hijacking, where either or both of these values can be forged by an attacker. SIP registration allows a user agent to identify itself to a registrar as a device at which the user (designated by an address of record) is located. A registrar may assess the identity asserted in the “From” header field of a SIP REGISTER message in order to determine whether this request can modify the contact addresses associated with the address-of-record in the “To” header field. While these two fields are frequently the same, there are many valid deployments in which a third-party may register contacts on a user's behalf. For example, in contrast to the “To” header field, the “From” header field of a SIP request can be modified arbitrarily by the owner of a user agent (UA). This opens the door to malicious registrations. An attacker that successfully impersonates a party authorized to change contacts associated with an address-of-record could, for example, de-register all existing contacts for a URI and then register their own device as the appropriate contact address, thereby directing all requests for the affected user to the attacker's device. This threat demonstrates the need for services that allow SIP entities to authenticate the senders of requests.
Accordingly, in light of these difficulties, a need exists for improved methods, systems, and computer readable media for verifying that the entity identified by the address of record and/or the display name is really the entity that is attempting to initiate a session.